1. Field of the Invention
The present invention relates to a communication infrastructure for a data processing apparatus, and a method of operating such a communication infrastructure.
2. Description of the Prior Art
A communication infrastructure for a data processing apparatus may take the form of interconnect circuitry arranged to interconnect a number of master devices with a number of slave devices. It is known for the communication infrastructure to comprise one or more crossbar circuits, a crossbar circuit also sometimes being referred to as a bus matrix. Such a crossbar circuit typically couples a group of master devices with a group of slave devices to enable transactions to be performed. In particular, each of the master devices provides a master interface coupled to the crossbar circuit and each slave device provides a slave interface coupled to the crossbar circuit. When a master device connected to the crossbar circuit wishes to communicate with a target slave device connected to the crossbar circuit, then a transaction is initiated from that master device's master interface (the initiating master interface) to the target slave device's slave interface (the target slave interface). Each transaction consists of an address transfer from the initiating master interface to the target slave interface, and one or more data transfers between that initiating master interface and that target slave interface. For a write transaction, these data transfers will pass from the initiating master interface to the target slave interface (in some implementations there will additionally be a write response transfer from the target slave interface to the initiating master interface), whilst for a read transaction these data transfers will pass from the target slave interface to the initiating master interface.
A crossbar circuit will provide a plurality of connection paths for coupling the various master devices and slave devices. The way in which transfers are routed via those connection paths will be dependent on the bus protocol employed within the crossbar circuit. A common type of bus protocol used within such crossbar circuits is known as a split transaction protocol. In accordance with such a split transaction protocol, the plurality of connection paths within the crossbar circuit provide at least one address channel for carrying address transfers and at least one data channel for carrying data transfers. An example of such a split transaction protocol is the AXI (Advanced eXtensible Interface) protocol developed by ARM Limited, Cambridge, United Kingdom. Herein, such split transaction protocols will also be referred to as multi-channel communication protocols.
As communication infrastructures increase in complexity, it is known to wish to connect together two or more separate crossbars, each crossbar having various master and slave devices connected thereto. Such a communication infrastructure is illustrated schematically in FIG. 1. As shown therein, a first crossbar 15 has a plurality of master devices 10 (also referred to as initiator devices) and a number of slave devices 20 (also referred to as target devices) connected thereto. Similarly, a second crossbar 35 has a plurality of master devices 30 and a plurality of slave devices 40 connected thereto.
In addition to transactions performed between the master devices 10 and the slave devices 20 connected to the first crossbar 15, or transactions performed between the master devices 30 and the slave devices 40 connected to the second crossbar 35, it is also necessary to enable transactions to be performed between a master device 10 connected to the first crossbar 15 and a slave device 40 connected to the second crossbar 35, or between a master device 30 connected to the second crossbar 35 and a slave device 20 connected to the first crossbar 15.
One way to seek to achieve such functionality is to provide a bidirectional link 25. When a transaction is initiated from a master device 10 to a slave device 40, the bidirectional link 25 needs to support a communication path 45. Similarly, for a transaction initiated by a master device 30 to a slave device 20, the bidirectional link 25 needs to support a communication path 50. When each of the crossbars 15, 35 employ a multi-channel interconnect protocol, then these communication paths 45, 50 need to provide the necessary channels to support that protocol, as is illustrated schematically in FIGS. 2A and 2B with reference to the example of the earlier-mentioned AXI protocol.
The AXI protocol provides a number of channels over which information and data are transferred when a transaction is performed from an initiating master interface 202 of a master device 206 (either the master 10 or the master 30 in the example of FIG. 1) to a target slave interface 204 of a slave device 210 (either the slave 20 or the slave 40 in the example of FIG. 1). In particular, a write address (AW) channel 205 is provided for carrying address transfers of write transactions, a write data (W) channel 210 is provided for carrying data transfers of write transactions, a write response (B) channel 215 is provided for returning transaction status information to the master interface at the end of a write transaction (such transaction status information indicating for example whether the transaction completed successfully, or whether an error occurred, etc), a read address (AR) channel 220 for carrying address transfers of read transactions, and a read data (R) channel 225 for carrying data transfers of read transactions. All five of these channels need to be supported by the communication path 200 passing from the initiating master interface 202 to the target slave interface 204. The crossbar 208 having associated slave interface 212 and master interface 214 (these crossbar interfaces also being referred to herein as internal interfaces to distinguish from the interfaces of the master and slave devices) can support these channels when routing communications between the initiating master interface 202 and the target slave interface 204, and hence everything operates correctly when the initiating master interface and target slave interface are coupled to the same crossbar (crossbar 15 or crossbar 35). However, support for the five channels is also needed where the initiating master interface and target slave interface are coupled to different crossbars, as will be the case for the communication paths 45, 50 of FIG. 1.
As shown in FIG. 2B, each of the five channels in FIG. 2A provide payload data passing from the source to the destination, along with a pair of handshake signals. In the AXI protocol, these handshake signals take the form of a valid signal passing over the channel in the same direction as the payload data, and a ready signal passing over the channel in an opposite direction to the payload data and the valid signal, but it will be appreciated that in other protocols different forms of handshake signals may be used, for example request/acknowledge handshake signals. For the AW, W and AR channels, the source is the initiating master interface and the destination is the target slave interface (such channels being referred to herein as forward channels), but for the B and R channels the source is the target slave interface and the destination is the initiating master interface (such channels being referred to herein as reverse channels).
A simple bidirectional link 25 may be constructed in the manner shown schematically in FIG. 3. FIG. 3 shows the same system as discussed earlier with reference to FIG. 1, but explicitly shows the various master interfaces 12, 32 associated with the master devices 10, 30, the various slave interfaces 22, 42 associated with the slave devices 20, 40, and the various internal slave interfaces 100, 120 and internal master interfaces 110, 130 provided within the two crossbars 15, 35. In the embodiment shown, the simple bidirectional link 25 consists of two separate communication paths. In particular, a first communication path 145 passes from the first crossbar 15 to the second crossbar 35, connecting an internal master interface 110 of the first crossbar 15 with an internal slave interface 120 of the second crossbar 35. In addition, a second, separate, communication path 155 is provided from the second crossbar 35 to the first crossbar 15, connecting an internal master interface 130 of the second crossbar 35 with an internal slave interface 100 of the first crossbar 15.
To support a transaction from an initiating master interface 12 coupled to the first crossbar 15 to a target slave interface 42 coupled to the second crossbar 35, the first communication path 145 needs to support all of the required channels of the multi-channel communication protocol, i.e. five channels for the AXI example discussed earlier with reference to FIG. 2A. Assuming the first communication path 145 does support all of these channels, then a communication path 140 can be established from the master interface 12 to the slave interface 42 as shown in FIG. 3, with the first communication path 145 forming part of that overall communication path 140.
Similarly, the second communication path 155 must also support all of the channels, and assuming it does so it will then be possible to establish a communication path 150 from an initiating master interface 32 coupled to the second crossbar to a target slave interface 22 coupled to the first crossbar 15, with the second communication path 155 forming part of that overall communication path 150.
However, as illustrated schematically in FIG. 4, this leads to the need to provide a significant number of connection lines within the bidirectional link 25 to provide the two separate communication paths 145, 155. In particular, as will be apparent from FIG. 3, the bidirectional link 25 is connected at either of its ends to an internal master interface and to an internal slave interface of an associated crossbar, and FIG. 4 shows how these connections are made at either end of the bidirectional link. Accordingly, at each end there will be both an internal master interface 200 and an internal slave interface 210. Assuming the earlier example of the AXI protocol, there will be five channels supported at each of these interfaces, thereby requiring the bidirectional link to support the group of connection lines 220 in order to facilitate both the first communication path 145 and the second communication path 155. For the example of an AXI interface, it can be seen from FIG. 4 that this requires ten connection lines to be provided for carrying payload data through the bidirectional link 25 of FIG. 3. However, it would be desirable to reduce the total number of wires required to support such a bidirectional link, since this would not only give rise to space savings, but would also significantly reduce wire routing complexity within the communication infrastructure.
A significant amount of research work has been performed in the area of a bidirectional Network-on-Chip (NoC) link for communicating between different components on a chip. For example, the article “Route Packets, Not Wires: On-Chip Interconnection Networks”, Proc. 38th Design Automation Conf. (DAC '01), pp. 684-689, June 2001, by W J Dally et al is an initial paper discussing packetised on-chip communication, from which the above-mentioned bidirectional NoC link was constructed. The book “Interconnection Networks—An Engineering Approach”, Morgan Kaufmann, 2002, by J Duato et al describes this bidirectional NoC link as an approach to enable the same packetised on-chip communication suggested by the above-mentioned W J Dally article. Further, the article “Xpipes: A Network-on-Chip Architecture for Gigascale Systems-on-Chip”, IEEE Circuits and Systems Magazine, Second Quarter, 2004, pp 18-31, by D Bertozzi et al examines the use of the bidirectional NoC link protocol as the basis for all on-chip communication in a high performance System-on-Chip (SoC). It also describes an IP library for creating such a system.
In accordance with the bidirectional NoC link approach, a link is provided with one channel existing in each direction. The channels have no visibility of masters or slaves, and only know a source and a destination. Information is packetised into multiple beats, with one header beat, one or more payload beats and one tail beat. The header contains routing information, the payload consists of the data, and the tail signifies the end of the packet. Such a bidirectional NoC link therefore has one channel for moving packets in a forward direction and another channel for moving packets in a reverse direction. Whilst such an approach allows forward and reverse data to be transmitted across any channel due to its packetised nature, it requires protocol conversion to take place at the interfaces to the bidirectional NoC link such that the data conforms to the same packet standard. The requirement for such protocol conversion adds cost and complexity to the design. Further, since the bidirectional NoC link has no visibility of masters or slaves, and merely supports one forward channel and one reverse channel, deadlock issues can arise when such an approach is used to try to link two crossbar circuits, where each crossbar circuit supports a multi-channel communication protocol. Such deadlock issues can result in the need for more complex cyclic dependency avoidance schemes, therefore requiring more silicon area and giving rise to increased energy dissipation. In particular these cyclic dependencies arise from trying to pass all channels of a multi-channel communication protocol over one bidirectional NoC link channel.
In systems with less complex interconnect requirements, it is known to employ non-split transaction protocols instead of the earlier discussed split transaction protocols. In accordance with a non-split transaction protocol, there is a fixed timing relationship between the address transfer of a transaction and the subsequent one or more data transfers of that transaction. An example of such a non-split transaction protocol is the AHB bus protocol developed by ARM Limited, Cambridge, United Kingdom. In accordance with the AHB protocol, no handshaking signals are used. In a development board previously produced by ARM Limited called the integrator core module (produced in association with the ARM 926, 946 and 966 processors) two boards were interconnected via a serial bus, within each board ARM's AHB bus protocol being used. Time division multiplexing techniques were used at the interface of each board to the serial bus in order to reduce the pin count at the interface of the board to the serial bus.
However, seeking to use TDM techniques to reduce pin count when coupling switching circuits using multi-channel communication protocols (i.e. split transaction protocols) would lead to a very inefficient design, and/or bandwidth issues, since all of the various channels would need to be catered for in the TDM approach, and some channels have significantly larger bandwidth requirements than others. In addition, some channels may be more latency-critical than others, and hence should be prioritised over others, and TDM approaches do not cater for this situation.